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The field of Avionics is advancing far more rapidly in terrestrial applications than in space flight 
applications. Spaceflight Avionics are not keeping pace with expectations set by terrestrial experience, nor 
are they keeping pace with the need for increasingly complex automation and crew interfaces as we move 
beyond Low Earth Orbit. NASA must take advantage of the strides being made by both space-related and 
terrestrial industries to drive our development and sustaining costs down. This paper describes ongoing 
efforts by the Avionics Architectures for Exploration (AAE) project chartered by NASA’s Advanced 
Exploration Systems (AES) Program to evaluate new avionic architectures and technologies, provide 
objective comparisons of them, and mature selected technologies for flight and for use by other AES projects. 
Results from the AAE project’s FY13 efforts are discussed, along with the status of FY14 efforts and future 
plans. 


I. Introduction 

The field of Avionics is advancing far more rapidly in terrestrial applications than in space flight applications. 
Spaceflight Avionics are not keeping pace with expectations set by terrestrial experience, nor are they keeping pace 
with the need for increasingly complex automation and crew interfaces as we move beyond Low Earth Orbit. NASA 
must take advantage of the strides being made by both space-related and terrestrial industries to drive our 
development and sustaining costs down. This paper describes ongoing efforts by the Avionics Architectures for 
Exploration (AAE) project chartered by NASA’s Advanced Exploration Systems (AES) Program to evaluate new 
avionic architectures and technologies, provide objective comparisons of them, and mature selected technologies for 
flight and for use by other AES projects. The AAE project team includes members from most NASA centers, and 
from industry. 

It is our intent to develop a common core avionic system that has standard capabilities and interfaces, and 
contains the basic elements and functionality needed for any spacecraft. This common core will be scalable and 
tailored to specific missions. It will incorporate hardware and software from multiple vendors, and be upgradeable in 
order to infuse incremental capabilities and new technologies. It will maximize the use of reconfigurable open 
source software (e.g., Goddard Space Flight Center’s (GSFC’s) Core Flight Software (CFS)). 

Our long-term focus is on improving functionality, reliability, and autonomy, while reducing size, weight, and 
power. Where possible, we will leverage terrestrial commercial capabilities to drive down development and 
sustaining costs. We will select promising technologies for evaluation, compare them in an objective manner, and 
mature them to be available for future programs. 

Our first major goal for FY13 was to demonstrate a plausible avionics architecture for a notional space station 
located at the 2 nd Earth-Moon Lagrange point (hereafter referred to as an “L2 Station”). This architecture was meant 
to provide a reasonable set of capabilities using avionics hardware that was either flight ready, or that could be made 
flight ready within 2 to 3 years. 

Our second major goal for FY13 was to provide a flexible avionics architecture that can be used to evaluate 
future concepts/architectures/components for both an L2 Station and other vehicles. This flexible architecture 
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accommodates equipment from multiple vendors in order to benchmark performance against a specific mission. It 
should allow us to take advantage of advances in technology being made by industry to drive our development and 
sustaining costs down, and facilitate efforts to incrementally infuse and validate architectural components in the 
future. 

The remainder of this paper describes our approach, technical areas of emphasis, integrated test experience and 
results, and future plans. As a part of the AES Program, we are encouraged to set aggressive goals and fall short if 
necessary, rather than to set our sights too low. We are also asked to emphasize providing our personnel with hands- 
on experience in development, integration, and testing. That we have embraced both of these philosophies will be 
evident in the descriptions below. 


II. Approach 

Our overall approach emphasizes the need for testing of different alternatives to provide objective evaluations of 
the relative merits of architectures and technologies. Technologies selected for evaluation include both “legacy” 
systems (e.g., MIL-STD-1553B), and those included in technology roadmaps produced by NASA’s Office of Chief 
Technologist (OCT), Avionics Steering Committee (ASC), and Space Communications and Navigaton (SCaN) 
Office. We recognize that any future exploration vehicles will likely be composed of a cluster of more specialized 
vehicles deployed at different times by various organizations/contractors (perhaps from different countries), and that 
we must address how these specialized vehicles interact during all mission phases. Although we are focused on 
avionics for Human Spaceflight, we are considering technologies applicable for both crewed and robotic vehicles. 

Operations on both the Space Shuttle and International Space Station (ISS) have shown the importance of an 
Ethernet LAN on a vehicle for crew use, both to ship large volumes of data (including imagery) and to enable the 
use of terrestrially available Commercial Off-The-Shelf (COTS) products (hardware and software). Both of these 
vehicles were initially designed without an Ethernet Local Area Network (LAN) which was then added at significant 
cost. The Space Shuttle was designed before the wide availability of LAN technology of any kind. The ISS was 
designed with a Payload Ethernet Hub Gateway (PEHG), but this capability was limited to routing payload data, 
principally for downlink via the Ku-Band system; it did not provide anything like a LAN for the crew to use. 

Based on our experience, Ethernet will be needed for any future crewed mission, and we want to leverage it for 
both COTS products and our terrestrial experience base. Hence, we decided to treat Ethernet as a fundamental part 
of the onboard architecture, and then evaluate what capabilities need to be added for command and control 
functions. Our initial areas of investigation center on the use of time-triggered and non-deterministic Ethernet for all 
vehicle functions. We are also looking at ways to interface an Ethernet backbone with other control bus protocols 
(1553B, SpaceWire, etc.). 

In addition, we are emphasizing the investigation of human interfaces; more powerful processors and network 
configurations; wireless technologies for both networking and instrumentation; and flexible long-haul 
communications technology. 

A. High-Level Challenges and Guidelines 

As part of our initial efforts, we identified a set of high level challenges: 

• Future exploration vehicles are undefined, but are likely to be an aggregate of multiple vehicles from 

multiple sources. This will drive sparing, redundancy, etc. 

• Size, Weight, and Power (SWAP) must always be minimized 

• Processing requirements exceed that which can be provided by existing Space Hardened Avionics (e.g., 

Power PC-based Rad750) 

• The Radiation Environment at HEO and beyond is much worse than it is at LEO (the environment with 

which HSF has the most operational experience). 

• Because of the radiation environment, we cannot rely on COTS hardware for additional processing 

capabilities as we have done on Shuttle and ISS (i.e., laptops aren’t likely to work reliably) 

• Exploration vehicle requirements will change/grow over the vehicle’s lifetime, as will the expectations set by 

Terrestrial State-of-the-Art. We need to accommodate these changes without undue expense. 
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These high level challenges, along with other project level decisions, lead to the following set of architectural 
guidelines: 

• Minimize Avionics SWAP in the Flight Vehicle. Use wireless LANs and sensor networks where possible. 

Use low/no power sensors (“Zero Wire”) whenever practical. Minimize total wiring on the vehicle (using 
topologies, VPNs, etc.). Minimize unique components for sparing. 

• Keep the architecture and design modular so we can launch incrementally. Allow capabilities to be 

integrated into the vehicle when they are needed, or earlier if it makes sense from an available launch mass 
perspective. 

• Minimize Cost. Use existing capabilities to avoid near-term DDT&E. Allow for growth using new 

technology to avoid future DDT&E. Allow for infusion of new technology to reduce sustaining effort. 
Look for places where improved Avionics can drive down overall vehicle costs. 

• Minimize Risk. Use proven technology for critical functions. Use existing capabilities to minimize schedule 

risk. 

• Minimize logistics and maintenance. Pay particular attention to the trade-off between utilizing precious 

habitable volume for mounting avionics inside the spacecraft versus the effort required for external 
maintenance via EVA. 

• Support Heterogeneity. We cannot expect every module of an aggregate vehicle to be the same. No one 

architecture/design will be an acceptable answer for everything. 

• Strive for “Commonality”. This cannot mean picking a set of components/boards/boxes to be used in 

multiple vehicles developed over long periods of time by different vendors, but it could mean picking the 
same components/boards/boxes to be used throughout a vehicle. It must mean developing a way for these 
different things to talk to each other. It should mean making sure that things of a similar type can be 
exchanged, to allow for minimal sparing. 

• Provide Ethernet on the vehicle for crew support. 

• Maximize the use of Core Flight Software (CFS). Another AES-funded effort at JSC is the Core Flight 

Software (CFS) project. Briefly stated, the Core Flight Software Project’s objective is to evolve and extend 
the reusability of GSFC’s Core Flight Software System into human-rated systems, thus enabling low cost, 
and rapid access to space. It was decided that the AAE project would make maximum use of CFS. This 
approach should maximize our ability to leverage platforms, resources and skills from synergetic 
programs/projects for development of next generation human-rated space software systems and utilize 
these products in direct support of development and certification of future manned programs. 

• Use IPAS and F.F. In order to maximize our return on investment, the AAE project has made extensive use 

of the Flight Deck of the Future (F.F) and the Integrated Power, Avionics, and Software (IPAS) capability 
developed by JSC Engineering. IPAS is multi-system environment where next generation flight systems 
can be tested and demonstrated. It provides multi-mission/multi- vehicle simulations, a common set of test 
services, access to a variety of actual sensors and effectors, and access via the Distributed Simulation 
Network (DSNet) to capabilities at multiple NASA centers 1 . The F.F focuses primarily on the human- 
machine interface. It allows us to evaluate different interface technologies together with personnel from 
Flight Crew Operations, Human Health and Performance, and other stakeholders. 

B. Standards and Specifications 

We established a lean set of interface standards & specifications for our use in FY13, with the expectation that 
they would be refined and extended as needed for our future efforts. 

Table 1. Interface Standards and Specifications 


Interface Type 

Standard/Specification 

1553 

MIL-STD-1553B 

Space Wire 

ECSS E-ST-50-12C 

Low Speed Serial 

EIA Standard RS-232-C 

High Speed Serial 

EIA Standard RS-422 

Ethernet 

IEEE 802.3 ™ - 2005 

Time Triggered Ethernet (TTE) 

SAE AS6802-201 1 

Wireless LAN 

IEEE 802.11™ -2005 

Wireless Sensors 

ISA 100.1 la-2012 
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C. Requirements 

Generic, high-level avionic system requirements were developed to aid in the objective evaluation of different 
architectures. Like the standards & specifications, these were established with the expectation that they would be 
refined and extended as needed for our future efforts. These requirements were not formally derived, but were 
established through a process of brainstorming, comparison with mission requirements sets being developed by 
NASA in the same timeframe, and vetting during Technical Interchange Meetings. These requirements are listed 
below. 

Spacecraft Vehicle Avionics. . . 

• Shall be capable of functioning in deep space (e.g., beyond LEO) 

• Shall be capable of supporting crewed missions 

• When uncrewed, shall be capable of autonomous operations for TBD duration 

• When uncrewed, shall be capable of being remotely operated from Earth, or elsewhere 

• Shall provide capabilities to support science, technology, and research payloads 

• Shall support visiting vehicles, both crewed and robotic 

• Shall support logistics resupply 

• Shall support expansion of vehicle capabilities 

• Shall support TBD EVR/EVA proximity operations 

• Shall support planetary/surface human/robotic operations 

D. Candidate Scenarios 

In order to define integrated test configurations which could be used to evaluate our capabilities, notional 
scenarios were developed. These included both crewed and uncrewed operations, as well as a docking between a 
Multi-Purpose Crew Vehicle (MPCV) and the L2 Station. Although a number of scenarios were considered, only 
two were used for our final integrated test. The first was a simple MPCV cruise. The second scenario began with an 
uncrewed L2 Station with MPCV on approach. The MPCV then docked to the L2 Station. Additional crewed 
operations (e.g., free-flyer operations) were conducted at different phases in this scenario. A detailed description of 
this scenario is provided in section IV- A. 

E. Avionics/Vehicle Functions 

A functional breakdown of vehicle avionics was performed to define needed capabilities for integrated tests, and 
begin the process of modeling our avionics systems and their simulation support. This functional breakdown 
included systems functions (e.g., Power Distribution) for each module of the integrated vehicle and Integrated 
Spacecraft functions (e.g., Integrated Power Control and Distribution) implemented via software. For FY13, these 
functions were condensed into the Integrated Test #3 Systems/Objectives shown in Figure 7, but they remain as a 
framework for modeling and evaluation of future technologies and architectures. 


III. Technical Areas of Emphasis 

Within the AAE project, we are emphasizing the investigation of human interfaces; more powerful processors 
and network communications; wireless technologies for both networking and instrumentation; and flexible long-haul 
communications technology. For these areas of emphasis, the high level challenges and architectural guidelines 
described in section II-C lead to specific technology goals to be addressed during FY13. For example: the challenge 
of minimizing size, weight, and power drives us to the guideline that wireless technologies be used where possible, 
and thus the FY13 goal to implement a wireless sensor network and begin to assess its limitations for spaceflight. 

A. Human Interfaces 

The goals of AAE Human Interface (HI) work are to identify, adapt, develop and mature innovative, integrated 
spaceflight human interface technologies that will meet the needs of NASA’s planned deep space crewed missions; 
and to infuse Human Systems Integration (HSI) from beginning to end of the project lifecycle, optimizing the 
system for crew time, personnel, training, human factors engineering, safety, health, survivability, and cost. Towards 
these ends, our efforts during FY13 were focused on the development of cockpit displays in F.F using various 
sensors (including imagery) and effectors located in IP AS. 

We also began work on a “Software GPU” to provide GPU functionality using radiation tolerant, safety critical 
processors suitable for use in a deep space environment. We are now working with the Kennedy Space Center 
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(KSC) and, through them, the Center for High-Performance Reconfigurable Computing (CHREC) to determine core 
requirements of Graphics Processing required by the JSC Human Interfaces team, and to determine low cost, high 
performance architecture options for future consideration. 

In partnership with Honeywell and the Orion program, we also conducted environmental testing on Active- 
Matrix Organic Light-Emitting Diode (AMOLED) displays - showing that the AMOLED displays remained 
functional with some degradation due to Thermal/Vac and radiation testing 2 . 

Ultimately, we intend to collect information about command & telemetry data rates; display view change events; 
number of displays with live data; data display rates; and cockpit configuration suitability using various display 
technologies and formats and various control techniques. 

In preparation for future exploration missions, we have begun to look at potential Telepresence capabilities - 
with a near-term focus on visual and auditory, and a longer term focus on tactile communication and sensory 
immersion. We are investigating the impacts of communication latencies and bandwidth variations on the perceived 
utility of Telepresence. 


B. Processors, Networks, and Instrumentation (PNI) 

In this area, our initial areas of investigation center on the use of both time-triggered and non-deterministic 
Ethernet for all vehicle functions. We are also looking at ways to interface an Ethernet backbone with other control 
bus architectures. We were able to provide a network configuration for multiple vehicles consisting of sub-nets, 
wired and wireless. Unfortunately, resource constraints prevented us from fielding a backbone based on time- 
triggered Ethernet during FY13, but this is an area in which we are making progress during FY14. 

We were able to demonstrate the use of computers of different construction, running diverse operating systems 
to function in a hot swap scenario. In achieving this, the capability and flexibility of Core Flight Software was 
essential. This approach will allow future flight vehicles a more flexible avionics architecture. 

Specifically, we loaded Core Flight Software and verified functionality on a Space Micro Proton400k-L (Dual 
Core PPC, T-TMR redundancy) using both Linux OS (Version 2.6.37) and VxWorks (Versions 6.8 & 6.9), and a 
Maxwell SCS-750 using VxWorks (Version 6.9). We were also able to load the CFS Core Flight Executive on a 
Raspberry Pi with Broadcom 2835 processor. 

During testing, we demonstrated some of the “-ilities” expected to reduce Hardware and Software design Cycle 
of a spacecraft avionics system, including interchangeability, scalability, flexibility, and maintainability. We were 
able to demonstrate two dissimilar machines running dissimilar Operating Systems OS’s acting in a Hot Spare 
Configuration. 

In order to interface our Ethernet backbone with other bus architectures, we have developed a Common Avionics 
Enabler (CAE). This device can be configured to handle interfaces with RS-232 and RS-422; interfaces with MIL- 
STD-1553B and Space Wire are in work. During FY13 we were able to develop a Device Discovery Framework for 
CAE which will permit inter-network Device Discovery during FY14. 

We have also utilized a Raspberry Pi processor as a Network Attached Device to monitor network traffic and 
observe hand controller commands. This was done to show that our network architecture was extensible - the flight 
bus can be scaled to include networked devices without interference (Consumer of data only) - and to demonstrate 
the power of small lightweight processor capabilities. 

C. Wireless Sensor Network (WSN) 

We are working to extend terrestrial, standards-based wireless technologies to space applications including 
sensing, control, and telerobotics. Relevant technologies have been prototyped and evaluated, and infused into the 
AAE architecture for further study. Our work also supports international space wireless standards development 
activities and is being coordinated with working groups chartered by the Consultative Committee for Space Data 
Systems (CCSDS). 

We have developed a CFS interface for an ISAlOO.lla WSN gateway and deployed two small ISAlOO.lla 
WSNs on a common vehicle network. We are streaming pressure, temperature, and simulated analog data over 
ISA100.1 la networks through CFS to F.F displays. 

We have developed an IEEE 802.11 (Wi-Fi) tele-operated free-flyer analog, shown in Figure 1. This device is 
remotely controllable over Wi-Fi, and can stream data and video. 
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Figure 1. A AE Tele-Operated Free-Fly er 


We have used this free-fly er analog to host an RFID interrogator payload and an ultra- wideband (UWB) 
location, tracking, and sensor data transport payload. Results from this UWB payload are shown in Table 2. 


Table 2. Accuracy and precision of 3 -Dimensional UWB location estimation 


Target Position 

(feet) 

T racked Position 

(feet) 


Bias 

(feet) 


Standard Deviation 

(feet) 

X 

y 

z 

X 

y 1 

z 

X 

y 

z 

x 1 

y 

z 

0 

14 

2.5625 

-0.0452 

14.0346 

2.768 

0.0452 

0.0346 

0.2055 

0.0631 

0.0663 

0.1472 

-8 

38 

2.5625 

-8.0394 

37.9153 

2.6532 

0.0394 

0.0847 

0.0907 

0.0701 

0.0737 

0.1951 

-16 

30 

2.5625 

-16.0383 

29.9854 

2.6812 

0.0383 

0.0146 

0.1187 

0.0697 

0.0744 

0.2337 

-16 

12 

2.5625 

-15.9962 

12.1353 

2.9072 

0.0038 

0.1353 

0.3447 

0.0749 

0.0793 

0.1822 

-10 

26 

2.5625 

-9.993 

26.0337 

3.0386 

0.007 

0.0337 

0.4761 

0.0596 

0.1002 

0.2344 


In the future we will be collecting a full range of network statistics (e.g., packet latency & loss rates, throughput, 
energy consumption, interference tolerance) for a variety of network types, including ISAlOO.lla, ZigBee, and 
802.1 In (WiFi). 


©.Communications Architecture and Disruption Tolerant Networking (DTN) 

With the recent advances in microelectronics, wireless transceivers are becoming more versatile, powerful, and 
portable. This has enabled software-defined radio (SDR) technology, where the radio transceivers perform the 
baseband processing functions entirely digitally, including modulation/demodulation, error correction coding, and 
compression/decompression. 

To achieve the maximum benefit, an SDR must not only be reconfigurable, but it must also have the ability to 
observe and measure the state of the operating environment and then intelligently learn and adapt as required. The 
AAE project is developing these capabilities, which are the fundamentals of cognitive radio (CR) communications. 

SDR and CR technologies will be of great benefit to NASA as they allow for increased interoperability due to 
radio flexibility, interference mitigation by detecting and avoiding potential interferers, higher data throughput by 
using scarce spectrum efficiently, and lower upgrade costs as the radios are able to adapt to different user/mission 
needs rather than going through expensive hardware replacement. 

During FY13, it was our goal to demonstrate a viable communications architecture for Human Exploration BEO; 
one that provides core command and telemetry, plus high rate downlink for science, video, and vehicle trending 
information. 
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During FY14, we will be working with our partners at Glenn Research Center (GRC) to port an STRS-compliant 
platform and libraries into our architecture. This will allow us to understand what it takes to implement STRS 
compliancy in a COTS SDR. 

Because of the cross-agency nature of a communications architecture, we hosted a Technical Interchange 
Meeting (TIM) with representatives from SCAN, AAE, MOD, and multiple NASA Centers to address 
Communications for Beyond Earth Orbit Human Exploration. At this TIM we were able to baseline a 
Communication Architecture for FY13 that included: long haul links from LEO, Near Earth and Deep Space back to 
Earth, using some variant of a Quadrature Phase Shift Keying (QPSK) and Binary Phase Shift Keying (BPSK); 
Internal Wireless Sensor Networks using ISA 100.11a; Wireless Local Area Networks using the 802.11 family; and 
Proximity and surface communications. This communications architecture is diagrammed in Figure 2. 



• 10 AG Service catalog for the mission phase (LEO, Near Earth and Deep Space) - some variant of QPSK and BPSK 

< > • Proximity (vehicle to vehicle) and Surface Communications 

• Determine capabilities needed 

• look at Proximity-1 and see if that is acceptable or if we need to develop Proximity-2 

< f • Wireless local area, mesh network -- 802.11 family variant 


< > • Potential Lunar Relay using Cubesat/Microsat 

Figure 2. AAE Baseline Communications Architecture for Human Exploration 


Disruption Tolerant Networking (DTN) protocol is a fundamental part of our communications architecture. 
NASA is developing the DTN protocol suite that extends the terrestrial Internet capabilities into highly stressed data 
communication environments where the conventional Internet protocols do not work well. The DTN protocol suite 
is being standardized by the Consultative Committee for Space Data Systems (CCSDS) and all of the DTN protocols 
will be international standards, supported by open-source software that can help users implement new capabilities. 

The development of the DTN protocol is not within the scope of the AAE project, but we are performing trade 
studies to determine the best location to host DTN within the spacecraft architecture, including key considerations 
such as size, weight and power, processor utilization, storage capacity, device real estate, and required data rates. 
The AAE project is also studying the impact of having DTN nodes at other locations within the end-to-end 
communication architecture, considering factors such as network reliability, implementation costs, and the need for 
international interoperability. 

In addition to baselining the communication architecture, we were able to implement a Space- Vehicle-to-Earth 
link in our testbed platform, integrate a proximity link with the Space- Vehicle-to-Earth link, and demonstrate end- 
to-end networked data transfer using Free Flyer video going over 802.11 wireless link to on-board vehicle network 
and over the Space-to-Ground link to the Control Center. 


7 

American Institute of Aeronautics and Astronautics 




We completed the pilot engineering program with MathWorks. This effort included the development of a 
Quadrature Phase Shift Key (QPSK) transceiver system using the MATLAB and Simulink model-based Hardware 
Description Language (HDL) design tools. 

We developed a generic baseband processor software application that can be used with multiple SDR platforms 
and supports: Framing of CCSDS space packets into Channel Access Data Units (CADUs); Data randomization and 
Reed-Solomon error correction; multiple data streams (Telemetry, Commands, Voice, Video, etc.); CCSDS 
formatted packets or generic User Datagram Protocol (UDP); DTN gateway for native or non-native DTN users 
with integration of ION 3.1.3; Web interface that automatically updates with useful statistics; XML-based 
configuration files for easy setup and deployment; fill data generation to keep radio link active; and CCSDS packet 
generation for testing/debugging. 

We developed a radio transceiver system using the GNU Radio open-source SDR development architecture 
targeted for the Universal Software Radio Peripheral (USRP). With this we were able to demonstrate multiple 
modulation schemes (BPSK, QPSK, GMSK) using a wide range of frequencies on a single platform. 

We developed a radio transceiver system using the MATLAB and Simulink model-based Hardware Description 
Language (HDL) design tools targeted for the Xilinx ML605 Field-Programmable Gate Array (FPGA) development 
board and the Analog Devices FMCOMMS 1 -EBZ transceiver daughtercard. When complete, the transceiver system 
will provide much more bandwidth, and thus higher data rates than the USRP in addition to other added capabilities. 

And finally, we were able to procure a low cost Programmable Ultra Lightweight System Adaptable Radio 
(PULSAR) SDR from MSFC. This radio is expected to arrive in Spring 2014. It supports S-Band Tx/Rx and X- 
Band Tx, BPSK and QPSK, and transmit rates of up to 150 Mbps and receive rates of up to 300 kbps 

In the future we intend to collect data regarding Baseband processor CPU utilization, FPGA logic utilization for 
radio/algorithm designs, Throughput rates with/without DTN Bundle Protocol/Licklider Transmission Protocol 
(BP/LTP), DTN storage requirements for various data types and scenarios, DTN node failure tolerance and recovery 
times, Packet processing latency and overhead, Packet loss rates and number of DTN retransmissions, and Radio 
energy consumption 

E. Model Based Systems Engineering (MBSE) 

NASA has initiated efforts to implement Model Based System Engineering (MBSE). In an effort to gain 
experience in this area, the AAE Project adopted this approach for our reference implementations. In the near-term, 
MBSE tools provide us with the flexibility to analyze and document a variety of architectures and share this 
information with other AES projects. Ultimately, this will support AAE goal of developing a reference 
implementation of the avionics architecture(s) that can be provided to industry (users) as a basis for standards and 
procurements. 

During FY13 we selected a Systems Modeling Language (SysML) based tool to support our MBSE 
implementation, and captured the AAE architecture using it. We initiated development of an AAE SysML 
component library, completed both a baseline SysML top-level Block Definition Diagram (bdd) of AAE’s Physical 
System Decomposition and Internal Block Diagrams (ibds) for Command & Data Handling (C&DH) and 
Communications (in their as-built configurations). 

Figure 3 shows an ibd representation of our vehicle avionics model (circa September 2013), comparable to the 
Rev 2.0 Architecture shown in Figure 4. 
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Figure 3. AAE Instantiation using SysML 


This model will evolve with design maturity, as more components are added and different architectures are 
evaluated. Our SysML model will bridge the gap between AAE and iPAS implementation (library vs. instantiation). 
It will support both flight vehicle analysis and IPAS testing activities. It will enable more automated IPAS 
reconfiguration and setup, as well as test data mining. 


F. Showing a Path-to-Flight 

Our project vision includes the development of architectures and system designs which can be used for flight 
programs/programs in both the near and long term. 

For the near term, this means that we must provide a point solution targeted for an identified mission in 2-3 
years. Essentially this solution must be a “good enough” answer from the options we have, which can be matured for 
flight with minimal effort and used as a basis for procurement specifications. 

For the long term, our intent is to build a “catalog” of multiple solutions which can be used “mostly off-the- 
shelf’ for a variety of situations. This catalog will include specific components and overall architectures. 
Recognizing that one size doesn’t fit all, each will be rated for suitability to different mission types. New 
technologies will be incorporated in a timely manner in order to take advantage of strides being made by industry to 
drive program development and sustaining costs down. This strategy should allow us to include vehicle “hooks & 
scars” for later augmentation; facilitate component repair, replacement, and upgrades; and take advantage of 
schedule slips during the development phase with improved hardware. 

Towards these ends, we defined notional processes that included an annual cycle of evaluation to be applied to 
new architectures/components as they are identified coordinated with a second process which, on request and/or 
annually, would develop a set of draft products and plans necessary for a selected avionics architecture to achieve 
PDR level of detail and issue necessary procurements. Gap/risk analyses would be conducted to identify the need for 
further investigation and maturation of architectures and technologies. This approach balances the Agency needs for 
continual technological innovation and stabilized technologies for program use. 

It was our intent to partially execute these processes during FY13. However, resource constraints combined with 
our belief that hand-on experience with hardware is of higher priority caused us to put these efforts on hold. 
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IV. Integrated Testing 

For the AAE Project, integrated testing provides a “capstone” opportunity for technology developed for each 
system to be integrated, operated, and tested as part of a candidate architecture during a realistic mission scenario. It 
also gives us the opportunity to test with larger JSC and NASA communities. 

Much of our effort during FY13 was geared around the support of 3 integrated tests distributed throughout the 
year. Integrated Test #1, held in March 2013, was used to ensure that we had all of our basic vehicle and test 
systems in place and to give our personnel experience in the process of testing their capabilities in IP AS. Integrated 
Test #2, held in August 2013, was essentially a dry-run for Integrated Test #3 - allowing us to determine the critical 
items we needed to work. Integrated Test #3, held in September 2013, was the culmination of our efforts and was 
accompanied by a one-day Technology Review of capabilities developed and test results. 

A. Mission Scenarios 

Key to the success of IT#3 was the definition of Mission Scenarios which would fully exercise the capabilities of 
our architecture and allow us to obtain objective performance data. Two scenarios were used, based on the work 
described in section II-F, but considerably modified to support test considerations. 

The first scenario was simply an “MPCV Cruise”, with no significant maneuvers involved. We did this in 
partnership with the CFS Project to assess the capabilities of the Honeywell 787 FMC running CFS (Ref. Fig. 4, #1). 

The second scenario was considerably more complex, involving MPCV docking with a L2 Station and 
operations using our free flyer analog and video streaming capabilities. During this scenario, MPCV was emulated 
using dual dissimilar hardware/OS flight computers running CFS (Ref. Fig. 4, #2), and a processor failure was 
introduced in our L2 Station module to demonstrate our “hot swap” capability. A detailed timeline for this scenario 
is shown in Table 3, together with references to our resultant architecture described in section IV-B, Fig. 4. 

Table 3. Scenario 2 Timeline, with Architecture References 
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Table 3. Scenario 2 Timeline, with Architecture References (cont) 

Phase B: Rendezvous & Docking, 2000m to 300m between MPCV and L2 Station 



Demonstrate MPCV power system 

Demonstrate MPCV propulsion with power and 

wireless pressure sensor telemetry 

Fail and Hot swap primary flight computers 

Space-to-Ground Communications Demo 

Command MPCV ECLSS fan "on" from MCC through 

JPL with DTN 

Display MPCV telemetry on MCC display 

Display MPCV video in MCC 


Command MPCV ECLSS fan "on" from MCC through 
SDR with DTN and communications LOS 


Ref# 

4 


4 


2 


3 


3 

3 


6 


Phase C: Rendezvous & Docking, 300m to 0m between MPCV and L2 Station 

Range: 300m - 10m 

Observe L2 Vehicle low cabin pressure on MPCV 
display through 802.11 proximity communications 

link 

Send Free Flyer from MPCV to L2 Vehicle to 

investigate prior to docking 

Navigate Free Flyer to L2 Vehicle via 802.11 network 
Stream video from Free Flyer to MPCV over 802.11 
link and to MCC via SDR 

Demonstrate RFID interrogation of autonomous 

sensor node and passive tags 

Demonstrate 3D position tracking with Ultra Wide 
Band wireless system 

Demonstrate wireless monitoring of solar panel 

perturbations from propulsion jet plumes 

Range: 10m - 0m 

Manual docking of MPCV to L2 vehicle 
Use MPCV cockpit to fly vehicle and dock 


Demonstrate MPCV displays 


Automatically establish wired networking between 
vehicles after docking 



Ref# 


7 


7 


8 


8 


9 


10 


9 


9 


11 
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B. Resultant Avionics Architecture 

Based on our FY13 goals, and inputs from our discipline leads and other stakeholders, a high-level architecture 
was defined for IT#3. This architecture is shown in Figure 4, along with architecture references tying it back to the 
Mission Scenario steps described in Table 3. The architecture includes representations of an MPCV, a typical L2 
Station module, and a free-fly er analog, all located within IP AS and F.F. It also includes links to locations around 
JSC and NASA which are used for special purpose emulations of systems, environments, and communications links. 


MPCV 

(Bay 1) 


Displays & 

RHC ! 

Controls 

THC 




Module (Typical) 

(Bus, Node, Aug, ETM P etc.) 


Free Flyer |8 


9 


""“I 

| 

• — i 

u 

! Audio 

%* % 

! Video j 

S02.ll 

Gateway 

1 


Displays 


Ethernet 

Power 

Fiber 

422 


RF 



Fit CPU 
B787 


1 

Fit CPU 
B787 






I 

Wireless 


Delay 

Gateway 

3 


RED = Reference to Scenario Timeline 


Figure 4. AAE Rev 2.0 Core Architecture, annotated with Mission Scenario steps 


C. Integrated Test Results 

Table 4 summarizes our integrated test results, by system and test objectives. Some objectives have been 
deferred into subsequent FYs, generally due to resource availability issues. Objectives tied to our AMOLEDS 
evaluation and Software GPU developments were not allocated to a specific Integrated Test, but are also shown in 
Table 4. 
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Table 4. Summary of AAE Integrated Test Results for FY 13. 


System 

Objective 

Summary Status 

Vehicle 

Dock MPCV to Waypoint at L2 

Complete. 


Route data between vehicles using wireless 
and hardline connections 

Complete. 


Display spacecraft status on other 
spacecraft during rendezvous 

Complete. 

C&DH 

Hot swap dissimilar flight computer during 
rendezvous 



Network load balancer 

Complete. Used SNMP command to switch for 
implementation 


Port mirror/SNMP heartbeat 

Deferred to FY14. Resource issue. 


Use Maxwell CPU in DSH 

Deferred to FY 14. Awaiting new chassis. 


Provide local boot capability for all flight 
computers 

Complete. 


Network Appliances 



Use Raspberry Pi appliance as network 
monitor 

Complete. 


Use Raspberry Pi to develop network map 

Deferred to FY14. Resource issue. 


Fly MPCV with Honeywell FMC 

Complete. GN&C software running with flight 
dynamics sim and can fire jets. 

Networks 

Use routers to dock vehicles 

Complete. 


Automatically route spacecraft data across 
wireless during prox ops and hardline once 
docked 

Complete. 


Use TT-E protocol for Honeywell FMCs 

Deferred to FY14. Resource issue. 


Route DSH data to L2 

Tested. Not fully implemented due to limited 
resources 

Human 

Interfaces 

Displays 



MPCV ECLSS 

Good data from B7 chamber and with ECLSS sim, 
still integrating MIS data to display 


MPCV thrusters (pwr & MIS) 

Lingering issues with display of MIS data 


MPCV TRAJ display (improvements) 

Complete. 


L2 power (DSH/AMPS) 

Complete except for crew display 


L2 ECLSS (from sim) 

Complete. 


MPCV out-the-window view 

Complete. 


MPCV centerline camera view 

Complete. 


"God’s eye" camera view 

Complete. 


Manual docking from F.F with displays 
and THC 

Complete. 


Complete AMOLED testing 

Complete. 


Test sGPU 

Complete. Preliminary tests show improvement 
when running on C925 vs. C903. 


Telepresence comparison 

Complete. 


13 

American Institute of Aeronautics and Astronautics 




















Table 4. Summary of AAE Integrated Test Results for FY 13 (cont). 


System 

Objective 

Summary Status 

Wireless 

Systems 

Complete CFS ISA 100.1 la gateway 

Complete. 


Expand ISAlOO.lla network with more 

Deferred to FY14, will coordinate with other AES 


MIS units 

Projects. 


Connect B7 ECLSS chamber with MIS 
and CFS gateway 

Complete. 


UWB tracking of free flyer 

Complete. 


Integrate 802.11 MIS for high rate sensor 
data 

Deferred to FY14. Resource issue. 


Demonstrate interference tolerance 

Deferred to FY14. Resource issue. 

Commun 

ications 

Space-to-ground link using new baseband 
processor and USRP 

Complete. 


Integrate new radio with new baseband 

Almost complete. Deferred to FY14 due to limited 


processor 

resources 


Integrate DTN into baseband processor 

Complete. 

Free Flyer 

Teleoperate from L2/MPCV 

Complete. 


Stream video to MCC 

Complete. 


RFID interrogator for passive sensors and 
inventory 

Complete. 


Add wireless actuation capability 

Deferred to FY14. Resource issue. 

Software 

Executable for Proton CPU 

Complete. 


Use c903 as star tracker computer 

Deferred due to lack of resources 


MPCV Telemetry app (Magic Sensor) 

Complete. 


Add CFDP to FC load 

Endian compatibility issue between CCSDS packet 
header and CFS. Deferred due to lack of resources 


AMPS telemetry app 

Complete except for crew display. 


Fix Star Tracker CFS app 

Deferred due to lack of resources 

Ground 

Systems 

Start MPCV from KSC LCC 

Complete. 


Transfer DOLILU file from KSC LCC to 
MPCV 

Deferred. Awaiting CFDP 


Add telemetry and displays in MCC OTF 

Deferred due to lack of resources 


Receive free flyer video 

Complete. 

GN&C 

Improve star tracker video processing 

Requires c903 computer. Deferred due to lack. 

MBSE 

C&DH models 

Ongoing work to improve fidelity of existing models 


Network models 

Ongoing work to improve fidelity of existing models 


Human interface models 

Ongoing work to improve fidelity of existing models 


Wireless models 

Need models for WAP and MIS 


Communications models 

Need models for BBSP and radio 


Free Flyer models 

Complete. 


System diagram 

Complete. 
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D. Technology Review 

In conjunction with Integrated Test #3, the AAE project held a Technology Review. This was used as an 
opportunity to describe to our stakeholders and colleagues the work that had been done, the results of our efforts, 
and the work we were considering for the future. Comments were solicited and captured, and these have been 
incorporated into our planning for FY14 and beyond. We plan to continue this approach in future years. 


V.Conclusions 

During FY13, the AAE Project was able to successfully demonstrate a plausible avionics architecture for a 
notional E2 Station. We were also able to make significant strides toward our goal of a flexible avionics architecture 
that can be used to evaluate future concepts/architectures/components for both our nominal F2 Station and other 
vehicles. 

Our Rev 2.0 architecture provides a common core system that has standard capabilities and interfaces, and 
contains basic core elements and functionality needed for any spacecraft. It consists of four key capabilities: 

• A common avionics package utilizing modern spaceflight avionics architectures and components to reduce 

development time and maximize sub-element commonality and reuse. 

• A prototype common inter-networked radio system for all future spacecraft, suits, and ground stations, 

allowing the replacement of the unique capabilities now required for each link with a single type of system 
throughout the HSF architecture, and resulting in improved operational efficiencies, reduced power, and 
mass savings. 

• Human Interface enhancements that are a mix of commercial and custom (where needed) components that 

are as common as possible across the AES projects. 

• Standardized model-based systems engineering and automated test capabilities to facilitate integration and 

test. 

If desired, this system can be scaled and tailored to any specified mission. The system incorporates hardware 
from multiple vendors, and reusable and reconfigurable open source software (e.g., GSFC CFS). 

Although strides have been made, there remains a great deal of work to do. Our FY14 efforts have been centered 
around incremental architectural upgrades applied to different mission scenarios. In FY15, we are planning to merge 
the AAE project with the CFS project, the DTN project, and some aspects of the Autonomous Mission Operations 
(AMO) project, all funded from AES. 

We remain committed to demonstrating the technical and economic benefits of our approach, but the amount of 
progress we are able to make is dependent on funding and resource constraints, along with the priorities set by the 
Agency for Human Spaceflight. 

Although our team already includes participants from most NASA centers and industry, we recognize the need to 
widen participation from NASA and other government agencies, add more industry and academic partners, and 
begin discussions with potential international partners during the coming years. We look forward to engaging these 
future stakeholders. 
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